Concurrent Long Spanning Edit Sessions using Change Lists with Explicit Assumptions

ABSTRACT

An approach is provided that receives a change request from a requestor. The change request includes metadata regarding the change, one or more changes, and one or more change assumptions corresponding to at least one of the changes. The change request is stored in a data store of pending requests. One or more systems are identified that correspond to each of the change assumptions. The identified systems are automatically queried with queries that correspond to the change assumptions. Query responses in response to the querying are received from the identified systems. The validity of each of the change assumptions is determined based on the received query responses. If the change assumptions are valid, then the changes included in the change request are processed. On the other hand, if at least one of the change assumptions is invalid, then the change request is rejected.

RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.12/770,824, filed Apr. 30, 2010, titled “Concurrent Long Spanning EditSessions Using Change Lists with Explicit Assumptions,” and having thesame inventors as the above-referenced application.

BACKGROUND

Information handling systems often include object models that can beedited by multiple users. Conflicts can arise when conflictingsubmissions are received that pertain to a common object. Lockingobjects is infeasible and overly burdensome when object editing sessionslasts a relatively long period of time. Conversely, simply allowingconcurrent edits of the same object can introduce many conflicts thatcan be difficult, or even impossible, to identify and resolve.

SUMMARY

An approach is provided that receives a change request from a requestor.

The change request includes metadata regarding the change, one or morechanges, and one or more change assumptions corresponding to at leastone of the changes. The change request is stored in a data store ofpending requests. One or more systems are identified that correspond toeach of the change assumptions. The identified systems are automaticallyqueried with queries that correspond to the change assumptions. Queryresponses in response to the querying are received from the identifiedsystems. The validity of each of the change assumptions is determinedbased on the received query responses. If the change assumptions arevalid, then the changes included in the change request are processed. Onthe other hand, if at least one of the change assumptions is invalid,then the change request is rejected.

The foregoing is a summary and thus contains, by necessity,simplifications, generalizations, and omissions of detail; consequently,those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, inventive features, and advantages of the present invention, asdefined solely by the claims, will become apparent in the non-limitingdetailed description set forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerousobjects, features, and advantages made apparent to those skilled in theart by referencing the accompanying drawings, wherein:

FIG. 1 is a block diagram of a data processing system in which themethods described herein can be implemented;

FIG. 2 provides an extension of the information handling systemenvironment shown in FIG. 1 to illustrate that the methods describedherein can be performed on a wide variety of information handlingsystems which operate in a networked environment;

FIG. 3 is a high level diagram showing interaction of the processes andentities used to provide concurrent long spanning edit sessions usingchangelists with explicit assumptions;

FIG. 4 is a flowchart showing steps taken by a requestor of a changerequest;

FIG. 5 is a flowchart showing steps taken by a change request managementsystem;

FIG. 6 is a flowchart showing steps taken to analyze requestassumptions;

FIG. 7 is a flowchart showing steps taken to check internal assumptions;

FIG. 8 is a flowchart showing steps taken to check external assumptions;and

FIG. 9 is a flowchart showing steps taken when a request is rejected.

DETAILED DESCRIPTION

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions.

These computer program instructions may be provided to a processor of ageneral purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions, which execute via the processor of the computer orother programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

Certain specific details are set forth in the following description andfigures to provide a thorough understanding of various embodiments ofthe invention. Certain well-known details often associated withcomputing and software technology are not set forth in the followingdisclosure, however, to avoid unnecessarily obscuring the variousembodiments of the invention. Further, those of ordinary skill in therelevant art will understand that they can practice other embodiments ofthe invention without one or more of the details described below.Finally, while various methods are described with reference to steps andsequences in the following disclosure, the description as such is forproviding a clear implementation of embodiments of the invention, andthe steps and sequences of steps should not be taken as required topractice this invention. Instead, the following is intended to provide adetailed description of an example of the invention and should not betaken to be limiting of the invention itself. Rather, any number ofvariations may fall within the scope of the invention, which is definedby the claims that follow the description.

The following detailed description will generally follow the summary ofthe invention, as set forth above, further explaining and expanding thedefinitions of the various aspects and embodiments of the invention asnecessary. To this end, this detailed description first sets forth acomputing environment in FIG. 1 that is suitable to implement thesoftware and/or hardware techniques associated with the invention. Anetworked environment is illustrated in FIG. 2 as an extension of thebasic computing environment, to emphasize that modern computingtechniques can be performed across multiple discrete devices.

FIG. 1 illustrates information handling system 100, which is asimplified example of a computer system capable of performing thecomputing operations described herein. Information handling system 100includes one or more processors 110 coupled to processor interface bus112. Processor interface bus 112 connects processors 110 to Northbridge115, which is also known as the Memory Controller Hub (MCH). Northbridge115 connects to system memory 120 and provides a means for processor(s)110 to access the system memory. Graphics controller 125 also connectsto Northbridge 115. In one embodiment, PCI Express bus 118 connectsNorthbridge 115 to graphics controller 125. Graphics controller 125connects to display device 130, such as a computer monitor.

Northbridge 115 and Southbridge 135 connect to each other using bus 119.

In one embodiment, the bus is a Direct Media Interface (DMI) bus thattransfers data at high speeds in each direction between Northbridge 115and Southbridge 135. In another embodiment, a Peripheral ComponentInterconnect (PCI) bus connects the Northbridge and the Southbridge.Southbridge 135, also known as the I/O Controller Hub (ICH) is a chipthat generally implements capabilities that operate at slower speedsthan the capabilities provided by the Northbridge. Southbridge 135typically provides various busses used to connect various components.These busses include, for example, PCI and PCI Express busses, an ISAbus, a System Management Bus (SMBus or SMB), and/or a Low Pin Count(LPC) bus. The LPC bus often connects low-bandwidth devices, such asboot ROM 196 and “legacy” I/O devices (using a “super I/O” chip). The“legacy” I/O devices (198) can include, for example, serial and parallelports, keyboard, mouse, and/or a floppy disk controller. The LPC busalso connects Southbridge 135 to Trusted Platform Module (TPM) 195.Other components often included in Southbridge 135 include a DirectMemory Access (DMA) controller, a Programmable Interrupt Controller(PIC), and a storage device controller, which connects Southbridge 135to nonvolatile storage device 185, such as a hard disk drive, using bus184.

ExpressCard 155 is a slot that connects hot-pluggable devices to theinformation handling system. ExpressCard 155 supports both PCI Expressand USB connectivity as it connects to Southbridge 135 using both theUniversal Serial Bus (USB) the PCI Express bus. Southbridge 135 includesUSB Controller 140 that provides USB connectivity to devices thatconnect to the USB. These devices include webcam (camera) 150, infrared(IR) receiver 148, keyboard and trackpad 144, and Bluetooth device 146,which provides for wireless personal area networks (PANs). USBController 140 also provides USB connectivity to other miscellaneous USBconnected devices 142, such as a mouse, removable nonvolatile storagedevice 145, modems, network cards, ISDN connectors, fax, printers, USBhubs, and many other types of USB connected devices. While removablenonvolatile storage device 145 is shown as a USB-connected device,removable nonvolatile storage device 145 could be connected using adifferent interface, such as a Firewire interface, etcetera.

Wireless Local Area Network (LAN) device 175 connects to Southbridge 135via the PCI or PCI Express bus 172. LAN device 175 typically implementsone of the IEEE 802.11 standards of over-the-air modulation techniquesthat all use the same protocol to wirelessly communicate betweeninformation handling system 100 and another computer system or device.Optical storage device 190 connects to Southbridge 135 using Serial ATA(SATA) bus 188. Serial ATA adapters and devices communicate over ahigh-speed serial link. The Serial ATA bus also connects Southbridge 135to other forms of storage devices, such as hard disk drives. Audiocircuitry 160, such as a sound card, connects to Southbridge 135 via bus158. Audio circuitry 160 also provides functionality such as audioline-in and optical digital audio in port 162, optical digital outputand headphone jack 164, internal speakers 166, and internal microphone168. Ethernet controller 170 connects to Southbridge 135 using a bus,such as the PCI or PCI Express bus. Ethernet controller 170 connectsinformation handling system 100 to a computer network, such as a LocalArea Network (LAN), the Internet, and other public and private computernetworks.

While FIG. 1 shows one information handling system, an informationhandling system may take many forms. For example, an informationhandling system may take the form of a desktop, server, portable,laptop, notebook, mobile internet device, or other form factor computeror data processing system. In addition, an information handling systemmay take other form factors such as a personal digital assistant (PDA),a gaming device, ATM machine, a portable telephone device, acommunication device or other devices that include a processor andmemory.

FIG. 2 provides an extension of the information handling systemenvironment shown in FIG. 1 to illustrate that the methods describedherein can be performed on a wide variety of information handlingsystems that operate in a networked environment. Types of informationhandling systems range from small handheld devices, such as handheldcomputer/mobile telephone 210 to large mainframe systems, such asmainframe computer 270. Examples of handheld computer 210 includepersonal digital assistants (PDAs), personal entertainment devices, suchas MP3 players, portable televisions, and compact disc players. Otherexamples of information handling systems include pen, or tablet,computer 220, laptop, or notebook, computer 230, workstation 240,personal computer system 250, and server 260. Other types of informationhandling systems that are not individually shown in FIG. 2 arerepresented by information handling system 280. As shown, the variousinformation handling systems can be networked together using computernetwork 200. Types of computer network that can be used to interconnectthe various information handling systems include Local Area Networks(LANs), Wireless Local Area Networks (WLANs), the Internet, the PublicSwitched Telephone Network (PSTN), other wireless networks, and anyother network topology that can be used to interconnect the informationhandling systems. Many of the information handling systems includenonvolatile data stores, such as hard drives and/or nonvolatile memory.Some of the information handling systems shown in FIG. 2 depictsseparate nonvolatile data stores (server 260 utilizes nonvolatile datastore 265, mainframe computer 270 utilizes nonvolatile data store 275,and information handling system 280 utilizes nonvolatile data store285). The nonvolatile data store can be a component that is external tothe various information handling systems or can be internal to one ofthe information handling systems. In addition, removable nonvolatilestorage device 145 can be shared among two or more information handlingsystems using various techniques, such as connecting the removablenonvolatile storage device 145 to a USB port or other connector of theinformation handling systems.

FIG. 3 is a high level diagram showing interaction of the processes andentities used to provide concurrent long spanning edit sessions usingchange lists with explicit assumptions. Requestor 310 submits requeststo change management system 350 for processing. In one embodiment, therequests are transmitted to change management system 350 from aninformation handling system utilized by the requestor via computernetwork 200. In this embodiment, the computer network facilitatescommunication between the requestors, that change management system, andsystems 360. Systems 360 are a set of factors that change assumptionsincluded with the request are checked against for validity. As shown,these systems include external factors (external systems 370) andinternal factors (internal systems 380). The change request includeschange list 320 which is metadata about the change request, changeassumptions 330, and the actual changes 340.

Change management system 350 reads the change assumptions and uses thechange assumptions to check the external and internal factors. Internalfactors correspond to internal systems 380 and can automatically bechecked using software that queries the internal systems based on thechange assumptions. External factors correspond to external systems 370,such as approval by a decision maker, etc. In addition, in oneembodiment, some of the external systems have the authority to modifychange assumptions. For example, in a purchasing scenario, an internalchange assumption may be that the requested item can be purchased if theprice is below an assumed threshold. An external system, such as amanager, may have the authority to change the internal change assumption(e.g., raise or lower the price threshold). In addition, both theexternal and internal systems can provide reasons for both approving,and rejecting, a change assumption. In one embodiment, each of theinternal change assumptions is checked each time one of the externalsystems is checked. For example, if three levels of management approval(external systems) are required, each of the internal change assumptionsare checked after each of the approvals is given. In this manner, theinternal systems can take into account changes that have occurredbetween submissions as well as take into account any modifications madeto the change assumptions by any of the external systems.

Change management system 350 receives approvals, denials, modifiedassumptions, and reasons from systems 360. Based on the receivedinformation, change management system 350 generates responses, such asapproval to perform the changes and rejections to the change request. Ifeach of the change assumptions included in the change request is valid,then the changes are processed (e.g., a requested file is updated, arequested item is purchased, etc.). On the other hand, if any one of thechange assumptions is invalid, then the change is rejected. In oneembodiment, rejected change requests are retained in a data store ofpending requests. In this embodiment, rejected change requests arere-submitted on a periodic basis (e.g., daily, weekly, monthly, etc.)until the request expires or until the invalid assumption(s) become(s)valid (for example, a manager rejection is changed to an approval) andthe included changes are processed. In one embodiment, a counter ismaintained of the number of times a change request has been processed.In this embodiment, the change request is removed from the data store ofpending changes (deleted) when the counter reaches a predetermined limit(e.g., after three submissions, etc.).

FIG. 4 is a flowchart showing steps taken by a requestor of a changerequest. Processing commences at 400 whereupon, at step 410, therequestor specifies a list of changes being requested to be appliedatomically as a set. The list of changes is stored in memory area 420.At step 430, the requestor specifies a list of change assumptions andthese change assumptions are stored in memory area 440. In oneembodiment, the change assumptions include both internal changeassumptions and external change assumptions. Also, in one embodiment,each of the change assumptions must be met (be valid) before any of thechanges stored in memory area 420 are processed. Finally, in anotherembodiment, the list of change assumptions may be generated or augmentedautomatically (for example, the system may see that a particularvariable value is being changed, and may add an assumption that thecurrent value of that variable is the value at the time the changerequest was created).

At step 450, the requestor specifies metadata for the change list whichis stored in memory area 320. Metadata can include the requestor'sinformation (e.g., name, identifier, contact information, etc.), achange narrative that describes the change request that is beingsubmitted, an active time period during which the change request can beprocessed, and a number of retries value that provides a predeterminedlimit on the number of times the change request should be retried beforeremoving the change request from the change request management system.

At step 470, the change request is packaged into change request datastore 480 (e.g., a computer file). The packaging process packages thespecified list of changes, the list of assumptions, and the specifiedmetadata into change request data store 480. At step 490, the changerequest (change request data store 480) is transmitted to the changerequest management system via computer network 200. Predefined process495 details the processing performed by the change request managementsystem when the change request is received (see FIG. 5 and correspondingtext for processing details).

FIG. 5 is a flowchart showing steps taken by a change request managementsystem. Processing performed by the change request management systemcommences at 500 whereupon, at step 510, the change request managementsystem receives change request 480 from a requestor. As shown, changerequest 480 includes the metadata, assumptions, and changes that werespecified by the requestor. At step 520, the received request iscompared with request submission rules 530 in order to determine if thechange request is valid. For example, an organization could establishthat only employees with a certain level can make various types ofrequests. If the requestor is not one of these employees, then therequest would be denied. A determination is made as to whether therequest is valid based on the comparison with the request submissionrules (decision 540). If the request is not valid, then decision 540branches to the “no” branch whereupon, at step 560, an error is returnedto the requestor informing the requestor that the request was denied andwill not be processed. On the other hand, if the request is valid, thendecision 540 branches to the “yes” branch whereupon, at step 550, thereceived request is stored in data store of pending requests 480.

Periodically, the change request management system processes therequests stored in data store 480. At step 570, the first change requeststored in data store 480 that is ready for processing is selected. Arequest is “ready for processing” based upon its metadata. For example,a pending request may have been previously rejected and is scheduled forweekly re-submission, in which case the pending request will not beselected at step 570 until a week has passed. At predefined process 575,the assumptions included in the selected request are analyzed and thechange request is processed (see FIG. 6 and corresponding text forprocessing details). A determination is made as to whether there aremore requests that are ready to be processed (decision 580). If thereare more requests ready to be processed, then decision 580 branches tothe “yes” branch which loops back to select the next request that isready to be processed from data store 480 and processes it usingpredefined process 575. This looping continues until there are no morerequests in data store 480 that are ready to be processed, at whichpoint decision 580 branches to the “no” branch whereupon, at step 590,processing waits for the next new request to arrive or for a given timeinterval (e.g., hourly, daily, etc.). If the time interval is reached,then step 590 branches to the “time interval” branch which loops back toprocess the requests pending in data store 480. If a new request isreceived, then step 590 branches to the “new request” branch which loopsback to receive the next request and process it as described above.

FIG. 6 is a flowchart showing steps taken to analyze requestassumptions. This routine is called at predefined process 575 shown inFIG. 5. FIG. 6 processing commences at 600 whereupon, at step 605,change list metadata 320 is checked in order to identify if the requesthas expired based on the active time period. A determination is made asto whether the request is still active (decision 610). If the request isno longer active, decision 610 branches to the “no” branch whereupon, atstep 615, the request is deleted from the data store of pendingrequests, and at step 620, the requestor is notified that the requesthas expired and has been deleted from the data store of pendingrequests.

On the other hand, if the request is still active, then decision 610branches to the “yes” branch whereupon a determination is made as towhether there are any internal assumptions included with the request(decision 625). If there are one or more internal assumptions, thendecision 625 branches to the “yes” branch whereupon, at predefinedprocess 630, the internal assumptions included in assumptions 440 areprocessed (see FIG. 7 and corresponding text for processing details). Onthe other hand, if there are no internal assumptions included in therequest, then decision 625 branches to the “no” branch bypassingpredefined process 630.

A determination is made as to whether the internal assumptions (if anywere checked) are valid (decision 635). If one or more of the internalassumptions are invalid, then decision 635 branches to the “no” branchwhereupon, at predefined process 680, the request is rejected (see FIG.9 and corresponding text for rejection processing details). On the otherhand, if the internal assumptions are valid, then decision 635 branchesto the “yes” branch whereupon a determination is made as to whetherthere are any external assumptions that need to be checked (decision640). If there are no external assumptions to be checked, then decision640 branches to the “no” branch whereupon, at step 650, the assumptionsare valid and the change list included in the change request isprocessed. The processing of the change request is different dependingupon the type of change being performed (e.g., document control,procurement, etc.). However, when the change request is processed, theexecuted change is recorded in data store 655 and the request is deletedfrom the list of active requests at step 658. On the other hand, ifthere are more external assumptions, then decision 640 branches to the“yes” branch whereupon predefined process 660 is executed to select thefirst external assumption from assumptions 440 and check it for validity(see FIG. 8 and corresponding text for external assumption processingdetails).

A determination is made as to whether the selected external assumptionwas invalid (decision 670). If the selected external assumption isinvalid, then decision 670 branches to the “yes” branch whereupon, atpredefined process 680, the request is rejected (see FIG. 9 andcorresponding text for rejection processing details). On the other hand,if the selected external assumption is not invalid, then decision 670branches to the “no” branch which loops back to step 605 to recheckwhether the request is still active and recheck the internalassumptions. In one embodiment, the internal assumptions are recheckedafter each external assumption is selected and determined to be valid.If the internal assumptions are still valid, then decision 635 willbranch to the “yes” branch and, if there are more external assumptionsto check, decision 640 will branch to the “yes” branch to select andcheck the next external assumption for validity and then loop backaround to again to recheck whether the request is still active andrecheck the internal assumptions. This selection and checking ofexternal assumptions and looping to recheck whether the request isactive and recheck the internal assumptions continues until all of theexternal assumptions have been selected and checked. When there are nomore external assumptions to check and all external assumptions andinternal assumptions are valid, then decision 640 branches to the “no”branch whereupon, at step 650, the change list included in the changerequest is processed.

FIG. 7 is a flowchart showing steps taken to check internal assumptions.This routine is called by predefined process 630 shown in FIG. 6.Processing of FIG. 7 commences at 700 whereupon, at step 710, the firstinternal assumption is selected from assumptions 440. At step 720, theselected internal assumption is checked by querying it against variousinternal systems 380. At step 730, one or more responses are receivedfrom the internal systems. A determination is made, based on thereceived responses, as to whether the selected internal assumption isvalid (decision 740). If the selected internal assumption is not valid,then decision 740 branches to the “no” branch whereupon, at step 750,the invalid assumption is recorded in invalid assumptions memory area760. A determination is made as to whether the system is set to gather alist of all invalid internal assumptions or whether to stop after oneinvalid internal assumption is identified (decision 770). If processingstops after the first invalid internal assumption is encountered, thendecision 770 branches to the “no” branch leading to decision 780described below, otherwise processing of the list of internalassumptions continues with decision 770 branching to the “yes” branch.

Returning to decision 740, if the selected internal assumption is valid,then decision 740 branches to the “yes” branch bypassing step 750 anddecision 770. A determination is made as to whether there are moreinternal assumptions to check (decision 775). If there are more internalassumptions to check, then decision 775 branches to the “yes” branchwhich loops back to step 710 to select the next internal assumption fromassumptions 440. This looping continues until all of the internalassumptions have been processed, at which point decision 775 branches tothe “no” branch leading to decision 780.

A determination is made as to whether one or more invalid internalassumptions were identified during the processing of the internalassumptions list (decision 780). If no invalid internal assumptions wereidentified, then decision 780 branches to the “no” branch whereuponprocessing returns at 790 with a flag indicating that the internalassumptions have been checked and are valid. On the other hand, if oneor more of the internal assumptions are invalid, then decision 780branches to the “yes” branch whereupon processing returns at 795 with aflag indicating that one or more internal assumptions are invalid.

FIG. 8 is a flowchart showing steps taken to check external assumptions.This routine is called by predefined process 660 shown in FIG. 6. FIG. 8processing commences at 800 whereupon, at step 810, the first externalassumption is selected from assumptions 440. At step 820 the selectedexternal assumption is checked against one or more external systems 370(e.g., external sources such as by sending a note to a manager forapproval, etc.). At step 830, a response is received from the externalsource(s).

A determination is made as to whether the external systems haverequested a modification of one or more of the assumptions included inassumptions 440. If the external system has requested a modification ofone or more of the assumptions, then decision 840 branches to the “yes”branch whereupon a determination is made as to whether the externalsystem has the authority to modify the requested assumption(s) (decision850). If the external system has the needed authority, then decision 850branches to the “yes” branch whereupon the assumption(s) selected by theexternal system is modified at step 860. Note that in one embodiment,the external system can modify both external and internal assumptionsincluded in assumptions 440. On the other hand, if the external systemdoes not have the authority needed to modify the selected assumption(s)then decision 850 branches to the “no” branch bypassing step 860.

A determination is made as to whether the selected external assumptionis valid (decision 870). If the selected external assumption is valid,then decision 870 branches to the “yes” branch whereupon processingreturns at 875 with a flag indicating that the external assumption isvalid. On the other hand, if the selected external assumption isinvalid, then decision 870 branches to the “no” branch whereupon, atstep 880, the invalid external assumption is recorded in invalidassumptions memory area 760 along with any reasons provided by theexternal system for rejecting the external assumption. Processing thenreturns to the calling routine at 895 with a flag indicating that theexternal assumption is invalid.

FIG. 9 is a flowchart showing steps taken when a request is rejected forany reason other than because the request is invalid. This routine iscalled by predefined process 680 shown in FIG. 6. FIG. 9 processingcommences at 900 whereupon, at step 910 message 970 (e.g., an emailnote, etc.) is prepared to the requestor with the message including thereasons that one or more of the internal and/or external assumptionswere invalid as recorded in invalid assumptions memory area 760. At step920, a counter that tracks the number of times that this request hasbeen rejected is incremented. At step 930, the incremented counter iscompared to a predefined limit, such as a limit provided by therequestor in request metadata 320. A determination is made as to whetherthe counter exceeds the number of retries set by the predefined limit(decision 940). If the counter exceeds the number of retries set by thepredefined, then decision 940 branches to the “yes” branch whereupon, atstep 950, the request is removed from data store of pending requests480. At step 960, a notice is added to rejection message 970 informingthe requestor that the request has been removed from the data store ofpending requests due to the predefined retry limit being reached.Returning to decision 940, if the counter does not exceed the retriesset by the predefined limit, then decision 940 branches to the “no”branch bypassing steps 950 and 960.

At step 980, request rejection message 970 is sent to requestor 310. Therequestor now has reasons for the rejection as well as knowledge ofwhether the request has been removed from the data store of pendingrequests. The requestor can analyze these reasons and determine ifchanges should be made to the request (or if a new request should becreated using steps shown in FIG. 4) and resubmitted to the changerequest management system shown in FIG. 3.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

One of the implementations of the invention is a client application,namely, a set of instructions (program code) or other functionaldescriptive material in a code module that may, for example, be residentin the random access memory of the computer. Until required by thecomputer, the set of instructions may be stored in another computermemory, for example, in a hard disk drive, or in a removable memory suchas an optical disk (for eventual use in a CD ROM) or floppy disk (foreventual use in a floppy disk drive). Thus, the present invention may beimplemented as a computer program product for use in a computer. Inaddition, although the various methods described are convenientlyimplemented in a general purpose computer selectively activated orreconfigured by software, one of ordinary skill in the art would alsorecognize that such methods may be carried out in hardware, in firmware,or in more specialized apparatus constructed to perform the requiredmethod steps. Functional descriptive material is information thatimparts functionality to a machine. Functional descriptive materialincludes, but is not limited to, computer programs, instructions, rules,facts, definitions of computable functions, objects, and datastructures.

While particular embodiments of the present invention have been shownand described, it will be obvious to those skilled in the art that,based upon the teachings herein, that changes and modifications may bemade without departing from this invention and its broader aspects.Therefore, the appended claims are to encompass within their scope allsuch changes and modifications as are within the true spirit and scopeof this invention. Furthermore, it is to be understood that theinvention is solely defined by the appended claims. It will beunderstood by those with skill in the art that if a specific number ofan introduced claim element is intended, such intent will be explicitlyrecited in the claim, and in the absence of such recitation no suchlimitation is present. For non-limiting example, as an aid tounderstanding, the following appended claims contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimelements. However, the use of such phrases should not be construed toimply that the introduction of a claim element by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim element to inventions containing only one such element,even when the same claim includes the introductory phrases “one or more”or “at least one” and indefinite articles such as “a” or “an”; the sameholds true for the use in the claims of definite articles.

1. A computer-implemented method comprising: receiving a change requestfrom a requestor, wherein the change request includes metadata regardingthe change, one or more changes, and one or more change assumptionscorresponding to at least one of the changes; storing, in a nonvolatilestorage medium, the request in a data store of pending requests;identifying one or more systems that correspond to each of the changeassumptions; automatically querying one or more of the identifiedsystems with one or more queries that correspond to the changeassumptions; receiving one or more query responses in response to thequerying; determining a validity, based on the received query responses,of each of the change assumptions; processing the one or more changesincluded in the change request in response to determining that each ofthe change assumptions is valid; and rejecting the change request inresponse to determining that at least one of the change assumptions isinvalid.
 2. The method of claim 1 wherein the change assumptions includeone or more internal change assumptions and one or more external changeassumptions, the method further comprising: determining the validity,based on the received query responses, of each checking an externalvalidity of each of the external change assumptions, wherein each of theexternal change assumptions is checked against an external source,wherein the processing of the one or more changes is performed inresponse to determining that each of the internal change assumptions andeach of the external change assumptions is valid.
 3. The method of claim2 further comprising: receiving, from one of the external sources, oneor more assumption changes; and modifying the one or more changeassumptions based on the assumption changes received from the externalsource.
 4. The method of claim 3 further comprising: prior to modifyingthe one or more change assumptions, verifying that the external sourcefrom which the assumption change was received is authorized to modifythe change assumptions corresponding to the received assumption changes,wherein the modification of the change assumptions is performed inresponse to the external source being verified.
 5. The method of claim 2further comprising: re-determining the validity of each of the internalchange assumptions after checking the external validity of each of theexternal change assumptions.
 6. The method of claim 1 wherein therejecting further comprises: preparing a message that includes one ormore reasons corresponding to sending the prepared message to therequestor.
 7. The method of claim 6 further comprising: incrementing acounter that tracks a number of times that the request has beenrejected; comparing the incremented counter with a predefined limit;removing the request from the data store of pending requests in responseto the comparison revealing that the request has been rejected thepredefined limit of times; and retaining the request in the data storeof pending requests in response to the comparison revealing that therequest has not been rejected the predefined limit of times, wherein therequest is reprocessed after a predefined amount of time has passed.